Much of what the average individual experiences as work, learning or play is accomplished through their interactions with computers and software. Billions of times a day, hundreds of millions of people interact with computers and software in their daily pursuits. Increasingly, people are faced with the challenge of working with multiple independent software systems to perform everything from the most mundane to the most complicated tasks. As used herein, “software system” refers to one or more applications, services, firmware, executed scripts, middleware, sets of functionality available via web pages, etc. that may share and/or request data. In many cases, no single software system contains all of the required information or functionality and it is often the individual's job to act as the point of connection amongst the software systems they use.
The lack of integration between most software systems means that the user is burdened with the complex, time-consuming and error-prone job of interacting with each software system individually and trying to perform a coordinated task across them. They spend valuable time copying and pasting and re-entering information, switching between the applications and individual web pages they need to use, while at the same time trying to remember the information that they obtained from one application that needs to be entered into the next.
Whether it is related to a person trying to use the Internet to research and arrange their dream vacation, an agent in a customer services department trying to resolve an issue, or a physician in an emergency ward trying to quickly access all of the information available about their patient, the problem surfaces everywhere people use software systems during their day. The effects of the problem are universal and far-reaching, negatively affecting individual productivity, costs, quality of work and satisfaction. In aggregate, the implications are staggering and represent an untapped potential source of improvement in almost every industry.
In some cases, software systems have been integrated to enable data sharing between them. System integration has traditionally been done in a point-to-point fashion using programmatic connections between the separate systems in an invocation/response pattern. Usually, the connection is made via an application programming interface (“API”) exposed by one of the software systems to be integrated. As these APIs are typically software system-specific, knowledge of various APIs is generally required when integrating new software systems with others. Each software system generally has different identifiers for data items, thus requiring the integrator to have knowledge of the data items and structures for each software system that is to be interacted with. Further, the events for each integrated software system need to make sense of the data moving between integrated software systems. These events are typically custom-designed and have to correspond with events occurring in other software systems. Examples of events include the completion of a database transaction, the appearance of a file in a directory, or the appearance of a message in a queue. Each of these events may require translating into something locally meaningful for each integrated software system.
Integration systems have been developed to handle the integration between different software systems, but these integration systems can bear all the same issues as encountered when directly integrating software systems.
Point-to-point integrations can work acceptably for small numbers of software systems with relatively-simple data to be shared. Due to the complexity of such integrations, they are generally reserved for enterprise systems and performed server-side. As the interaction of each software system with each other software system is explicitly programmed, the integration of each additional software system requires significantly-increased effort. Another issue is that it is generally very difficult for a third party to enhance the integration between software systems.
Yet another issue is that data persistence is not handled very well in most integrations. During the processing of a transaction, if a software system responsible for performing a task is not present, generally the transaction will fail. In order to instill robustness into such integrated software systems, event-handling has to be added as failsafes for various scenarios, adding further to the complexity of such integrations.
Server-side integration becomes even more challenging with so many widely-separated software systems coming together only on a computing device being used by an end-user and, often, on an ad-hoc basis.
One solution proposed, and deprecated, for data sharing by Google Inc is referred to as GOOGLE® gadgets. The proposal describes a publish-subscribe framework to pass messages from one gadget to another. GOOGLE® gadgets are canned sets of functionality that can be included in a web portal, such as iGoogle. Google Inc. previously supported this functionality which would not be present in other portals. Gadgets with data to share would publish the data using a set of defined identifiers via channels, as long as the gadgets were aware that at least one other gadget was interested in the data. Gadgets interested in the data would declare their interest in knowing when the values of those data items have changed. As the data is pushed via channels at the time there is a change, however, the state of the data may be unavailable to new gadgets. Further, gadgets have to have been programmed with knowledge of the defined data identifiers. This solution is specific to GOOGLE® gadgets and is not portable to other types of software systems.
It is therefore an object of the invention to provide a novel method and system For sharing data between software systems.